Hi, I drew up a list of some things I've been thinking about recently. I would appreciate it if some of you would read it over and tell me what you think about them. Right now its a very rough outline, I didn't bother checking spelling, dotting all the i's etc. Some of the ideas are probably unrealistic (as far as unix is concerned) while others could be done (and some are being done) today. Tim N. ----- scope of discussion ------------------- attacks considered: network user without local account running services on local machine as priveledged or unpriveledged user or creating/altering/reading files on the filesystem as priveledged or unpriveledged user. local user changing from his user id to the id of another user or reading/altering/creating files as another user. priveledged programs -------------------- trusted programs run in roots .cshrc,.profile,.login,.logout, etc. run in a cronjob run from system startup run from inetd suids Changes ------- - run network daemons with lower priveledges. discussion: Why are so many net daemons run as root? - collect suid programs into common directory, or perhaps a seperate directory for uid/gid. (both in src and bin form). rationale: Increase awareness of security critical programs. Make it easier to check all suid programs at once. - collect daemons into common directory (done already - /usr/libexec in bsd). rationale: see above. - database of priveledged programs and dependencies. Ie config files, temp files, directories, databases, etc. rationale: Keep track of assumptions in security critical programs. Avoid holes that arise out of changing an assumption (example making utmp world readable). Make it easier for automated checks (ie. world writeable directories like preserve and msgs). - per-process "trusted users" information. Only run binaries owned by a trusted user. discussion: simple way to do this is to put this functionality in the shell. To be really effective the functionality would have to be in the kernel exec code. This means the process structure (or maybe the credential structure) would have to have a uid list of trusted users. rationale: reduce the risk of trojan horse attacks. - non suid binaries owned by bin. bin considered priveledged. ie nfs remaps bin as well as root. rationale: better organization. Remove some of the "root clutter". offload as much as possible from the root uid. discussion: This might not be a good idea for the "trusted" binaries since root will run these files thus making bin equivalent to root. (As for nfs, nfs needs finer controls anyway). - system list of users allowed to use suid and sgid. Suid binaries not run if file owner not allowed to use suid/sgid. rationale: reduce the ability to store priveledge on a filesystem. - secure network services. authentication and encryption. point to point encryption in socket layer? Change services that rely solely on addresses for authentication to rely on additional or other information. Replace the priveledged ports model. discussion: To replace priveledged ports a "trust" server could be setup. This server would be on a well known port which would be hard to get. Trusted hosts can be done away with or complemented with private keys (one set of keys per "trust") or a public key system (one secret key per host). rationale: lower the risk of passive network attacks. Decouple network priveledge (packet filter access, "priveledged ports") from root priveledges. - finer grained priveledges. ie. net -> raw sockets, priveledged ports, etc. rlogin,rsh,etc become suid net. net - raw sockets, priveledged ports, packet filters, routing tables console - console and keyboard device. X servers. fs - quotas. uucp - modem kmem - read kmem rationale: Priveledged programs run with least priveledge required. - uid/gid passing over sockets. Library functions to make passing uids, gids and fds easier. Support for multiple uids per process (there is already uid, saved uid and effective uid). Ability to disable and reenable any of the uids. (This can be done more effectively with a bitmask than having a seperate "saved uid" variable). Ability to specify how priveledges get inherited (maybe not necessary). rationale: Add flexibility to security model. Make security features easier to use. Move closer to a capabilities based system. - program to run a process with a lower priveledge. Run programs in startup,cshrc,etc with minimal priveledge. Database of programs/priveledge requires that would be used by shell to lower priveledge before running certain programs. rationale: Programs run by a priveledged user don't always need priveledge. Run with least priveledge. Reduce the risk of trojan horse attacks. - capability based security model. Passing of priveledges. Ability to create new capabilities with a subset of a capability as in VSTa. Disabling of priveledges. Multiple priveledges per process. Security server for giving away priveledges to certain programs (is this possible to do in a secure way) to replace suid/sgid. Security server for requesting priveledges. rationale: Finer grained security model. Run programs with least priveledge required. Reduce coupling of filesytem security with system security. Support the transition from host security to distributed network security.